微服務(wù)

當(dāng)我們談?wù)撐⒎?wù)的時(shí)候粱腻，總避免不了說(shuō) Spring Cloud / Dubbo，這些微服務(wù)架構(gòu)的采用尼夺，確實(shí)達(dá)到了我們對(duì)他的期許：分布式尊残、熔斷/限流、高可用淤堵、可擴(kuò)展夜郁、分離關(guān)注、鏈路追蹤粘勒、小團(tuán)隊(duì)快速迭代竞端。

然而，微服務(wù)架構(gòu)的引入在解決單體應(yīng)用的一些問(wèn)題的同時(shí)庙睡，也給我們帶來(lái)了新的復(fù)雜度：

• 更多的技術(shù)組件
• 更多的部署單元
• 更復(fù)雜的部署腳本

作者在落地 Spring Cloud 微服務(wù)架構(gòu)的過(guò)程中事富，設(shè)計(jì)了如下圖所示的微服務(wù)參考架構(gòu)：

image-20190731230110206

該圖的左側(cè)是 DevOps 平臺(tái)，涵蓋構(gòu)建乘陪、測(cè)試统台、包管理、部署及運(yùn)維啡邑、監(jiān)控及評(píng)估贱勃。右側(cè)是運(yùn)行時(shí)平臺(tái)，分成互聯(lián)網(wǎng)層谤逼、展現(xiàn)層贵扰、微服務(wù)層、數(shù)據(jù)層流部。

#運(yùn)行時(shí)環(huán)境：

• 展現(xiàn)層主要是前端項(xiàng)目（Vue戚绕、微信小程序等），通過(guò)服務(wù)網(wǎng)關(guān)的路由調(diào)用微服務(wù)層 SpringBoot 實(shí)現(xiàn)的各種業(yè)務(wù)接口枝冀；一個(gè)大型互聯(lián)網(wǎng)產(chǎn)品中舞丛，需要多少個(gè)展現(xiàn)層的前端項(xiàng)目主要取決于兩個(gè)因素：該產(chǎn)品有多少中類型的參與方、每一種參與方各有多少種渠道接入方式果漾。例如球切，某交易撮合平臺(tái)，其需要的展現(xiàn)層項(xiàng)目如下列表所示：

展現(xiàn)層項(xiàng)目由于參與方不同绒障，賬號(hào)體系也就不同吨凑，因此，鑒權(quán)授權(quán)的邏輯也有較大的差異端盆，基于這樣的考慮怀骤，我們?yōu)椴煌恼宫F(xiàn)層項(xiàng)目各自部署對(duì)應(yīng)的接入網(wǎng)關(guān) Spring Cloud Gateway费封。

• 微服務(wù)層的項(xiàng)目包括 Spring Cloud Gateway 的主要組件，例如：服務(wù)注冊(cè) Eureka蒋伦、服務(wù)網(wǎng)關(guān) Spring Cloud Gateway弓摘、實(shí)現(xiàn)微服務(wù)的 Spring Boot項(xiàng)目，還有一些服務(wù)層用到的中間件（消息隊(duì)列 Rabbit MQ痕届、緩存服務(wù) Redis等）

  服務(wù)層里韧献，項(xiàng)目數(shù)量最多的類型是實(shí)現(xiàn)微服務(wù)的 Spring Boot 項(xiàng)目。使用微服務(wù)架構(gòu)研叫，如何將單體應(yīng)用的各個(gè)模塊拆分成多個(gè)微服務(wù)單元锤窑，一直一個(gè)大家很關(guān)注卻未能深入探討的問(wèn)題。作者設(shè)計(jì)過(guò)多個(gè)微服務(wù)系統(tǒng)的架構(gòu)之后嚷炉，認(rèn)為渊啰，一個(gè)合理的服務(wù)拆分方式是以領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的結(jié)果作為參考，可以將每一個(gè)領(lǐng)域的上下文邊界對(duì)應(yīng)為一個(gè)微服務(wù)單元申屹。如此一來(lái)绘证，在使用服務(wù)網(wǎng)關(guān)隔離的前后端分離的微服務(wù)架構(gòu)中，前端微服務(wù)劃的分重要依據(jù)是參與方類型 + 接入渠道哗讥，后端微服務(wù)劃分的重要依據(jù)是領(lǐng)域設(shè)計(jì)的上下文邊界嚷那。

  作為一個(gè)完整的交易撮合平臺(tái)，涉及到的業(yè)務(wù)領(lǐng)域較為龐大杆煞，涉及到數(shù)十個(gè)業(yè)務(wù)問(wèn)題領(lǐng)域魏宽。合理拆分的微服務(wù)架構(gòu)，可以使得企業(yè)對(duì)不同的問(wèn)題領(lǐng)域分而治之决乎。

#DevOps平臺(tái)

運(yùn)行時(shí)環(huán)境采納了微服務(wù)架構(gòu)后队询，因?yàn)榧夹g(shù)組件的多樣性、業(yè)務(wù)領(lǐng)域的多樣性瑞驱，導(dǎo)致了微服務(wù)拆分之后娘摔，產(chǎn)生了數(shù)十個(gè)微服務(wù)可部署單元窄坦。這個(gè)情況給技術(shù)團(tuán)隊(duì)帶來(lái)了前所未有的挑戰(zhàn)：

• 構(gòu)建次數(shù)多唤反，人工難以完成

• 部署實(shí)例多，無(wú)法人工管理

• 運(yùn)行實(shí)例多鸭津，出了故障不好定位

在解決這些問(wèn)題的過(guò)程中彤侍，最終摸索出了一套以 Kubernetes 為關(guān)鍵環(huán)節(jié)的微服務(wù) DevOps 平臺(tái)。

image-20190809173443557

如上圖所示逆趋，假設(shè)有20+ 開(kāi)發(fā)人員盏阶，

• 每天提交100次代碼，將每天產(chǎn)生100余次構(gòu)建和自動(dòng)測(cè)試闻书，新增80-100個(gè) docker 鏡像
• 每天更新開(kāi)發(fā)環(huán)境名斟、測(cè)試環(huán)境各一次脑慧，每次重新部署20+ 個(gè) docker container
• 每周更新 STAGING 環(huán)境 3-4次，每周更新 PRODUCTION 環(huán)境 1-2 次

在單體應(yīng)用的時(shí)候砰盐，即使是手工打包也是能夠完成每天發(fā)布新版本的要求的闷袒。但是在微服務(wù)環(huán)境下，這個(gè)工作就必須交給 DevOps 的 Pipe Line 來(lái)完成岩梳。

DevOps 在構(gòu)建階段的主角是 GitLab囊骤、npm、maven冀值、docker也物、Harbor等工具集，在部署和運(yùn)維環(huán)節(jié)的主角就是Kubernetes了列疗。

#微服務(wù) + Kubernetes

最開(kāi)始嘗試容器化的時(shí)候滑蚯，使用了 docker、docker-compose抵栈，但是docker-compose的編排能力有限膘魄，在考慮分布式方案時(shí)，從 docker swarm竭讳、kuberenetes 之中選擇了 Kubernetes创葡，然而，Kubernetes 相較于 docker-compose绢慢，有一個(gè)很高的學(xué)習(xí)門檻灿渴，集群的安裝管理、YAML 文件的編寫胰舆、多環(huán)境（開(kāi)發(fā)環(huán)境骚露、測(cè)試環(huán)境、準(zhǔn)生產(chǎn)環(huán)境缚窿、生產(chǎn)環(huán)境）的配置棘幸、分布式環(huán)境下的問(wèn)題診斷和性能優(yōu)化等，一系列的問(wèn)題需要解決倦零，團(tuán)隊(duì)中也出現(xiàn)一些抵觸情緒误续，對(duì)新事物持觀望的態(tài)度。

Kubernetes在諸多大廠的成功實(shí)施扫茅，仍然讓我們堅(jiān)信這條道路的正確性蹋嵌。為了解決 Kubernetes 學(xué)習(xí)門檻高、YAML 文件編寫復(fù)雜等一系列現(xiàn)實(shí)中的困難葫隙，我們研發(fā)了 Kuboard栽烂，一款 Kubernetes 的圖形化管理控制工具。

Kuboard 誕生于 Spring Cloud 微服務(wù)落地的實(shí)踐過(guò)程中，他在管理和使用 Kubernetes 的時(shí)候腺办，也更多地是從微服務(wù)的視角來(lái)看待 Kubernetes焰手。

具體體現(xiàn)在如下三個(gè)視角：

• 集群概覽
• 名稱空間
• 工作負(fù)載

#集群概覽

從管理和部署微服務(wù)的視角來(lái)看，微服務(wù)應(yīng)用是分布式應(yīng)用怀喉，應(yīng)該部署在一個(gè)分布式集群當(dāng)中咆繁，這個(gè)集群由諸多計(jì)算資源和存儲(chǔ)資源組成筹误，微服務(wù)本身不應(yīng)該關(guān)心最終使用了哪個(gè)計(jì)算節(jié)點(diǎn)萨驶，持久化存儲(chǔ)被存放在什么位置谋减；為了更好地利用資源，一個(gè)集群應(yīng)該被劃分成多個(gè)名稱空間估灿，每個(gè)名稱空間內(nèi)可以部署一整套微服務(wù)應(yīng)用崇呵，名稱空間之間不應(yīng)相互干擾。

如下圖所示：Kuboard 集群概覽界面

image-20190723105809872

Kuboard 集群概覽視角馅袁，映射了 Kubernetes 中的如下幾個(gè)重要概念：

• Cluster
• Node
• Storage Class / Persistent Volume
• Namespace

#名稱空間

在集群概覽界面中域慷，點(diǎn)擊一個(gè)名稱空間，可以進(jìn)入Kuboard名稱空間界面汗销。一個(gè)名稱空間內(nèi)部犹褒，是微服務(wù)部署相關(guān)的所有重要元素。與本文開(kāi)頭的微服務(wù)參考架構(gòu)相匹配弛针，Kuboard 認(rèn)為叠骑，微服務(wù)的主要分層包括：

• 展現(xiàn)層
• 網(wǎng)關(guān)層
• 服務(wù)層
• 持久層
• 中間件層
• 監(jiān)控層

如下圖所示：Kuboard名稱空間截圖

image-20190721154650916

Kuboard 名稱空間視角，映射了 Kubernetes 中的如下幾個(gè)重要概念：

• Workload（Deployment削茁、StatefulSet宙枷、DaemonSet）
• Service（微服務(wù)上方如果有淺藍(lán)色長(zhǎng)條塊，說(shuō)明該微服務(wù)有配置 Service）
• Ingress（微服務(wù)上方如果有黑色短條塊茧跋，說(shuō)明該微服務(wù)有配置 Ingress）
• Secrets（用來(lái)配置私有 docker 鏡像倉(cāng)庫(kù)的用戶名密碼慰丛、HTTPS 的證書等信息，可在創(chuàng)建微服務(wù) Workload 時(shí)引用）
• ConfigMap（配置瘾杭，用來(lái)存儲(chǔ)配置信息诅病，可定義微服務(wù)的公共環(huán)境變量，并在創(chuàng)建微服務(wù) Workload 時(shí)引用）
• Persistent Volume Claim（存儲(chǔ)卷聲明粥烁，用來(lái)聲明存儲(chǔ)卷贤笆，可在創(chuàng)建微服務(wù) Workload 時(shí)引用）

Kuboard 名稱空間界面中，還為典型的運(yùn)維場(chǎng)景提供了便捷的操作入口页徐，例如：

• 創(chuàng)建工作負(fù)載（通過(guò)工作負(fù)載編輯器完成微服務(wù)應(yīng)用的部署苏潜，而不是編寫冗長(zhǎng)的YAML文件，再使用復(fù)雜的 kubectl 命令）
• 導(dǎo)出工作負(fù)載（選擇名稱空間中的微服務(wù)元素变勇，導(dǎo)出到一個(gè)文件中）
• 導(dǎo)入工作負(fù)載（將 Kuboard 導(dǎo)出的 YAML 文件導(dǎo)入到一個(gè)新的名稱空間中，通過(guò)導(dǎo)出和導(dǎo)入的功能，用戶可以快速的將開(kāi)發(fā)環(huán)境復(fù)制成測(cè)試環(huán)境）
• 容器組列表（查看當(dāng)前名稱空間中的容器組搀绣，可批量刪除選中容器組飞袋，刪除容器組后，Kubernetes將重新 Schedule一個(gè)容器組以替換被刪除的容器組链患，此時(shí)將重新抓取鏡像巧鸭，此特性可用于測(cè)試環(huán)境中在 image tag 不改變的情況下的版本更新）
• 調(diào)整鏡像版本（修改容器鏡像的標(biāo)簽，此特性用于在正式環(huán)境中進(jìn)行版本更新的操作）
• 高亮顯示包含錯(cuò)誤事件的微服務(wù)（如截圖中紅色的微服務(wù) busybox）

#工作負(fù)載

從名稱空間界面中點(diǎn)擊一個(gè)工作負(fù)載（微服務(wù)）麻捻，可進(jìn)入 Kuboard 工作負(fù)載編輯器界面纲仍。Kuboard 當(dāng)前已經(jīng)支持的工作負(fù)載 Workload 類型有：Deployment / StatefulSet / DaemonSet。

Kubernetes 中贸毕，與 Workload 相關(guān)的概念非常多郑叠，Kuboard 從微服務(wù)部署的實(shí)際需要出發(fā)，按照下圖所示的方式理解這些相關(guān)概念：

image-20190731221630097

Kuboard 工作負(fù)載視圖中明棍，關(guān)聯(lián)的 Kubernetes 中如下幾個(gè)重要的概念：

• Label / Label Selector
• Workload Controller 工作負(fù)載控制器（Deployment / StatefulSet / DaemonSet）
• Volume 數(shù)據(jù)卷
• ImagePullSecrets （Docker 倉(cāng)庫(kù)用戶名密碼乡革，用于訪問(wèn)私有 docker 鏡像倉(cāng)庫(kù)）
• ServiceAccount
• Container 容器
• Service 訪問(wèn)方式
• Ingress 互聯(lián)網(wǎng)入口

Kuboard 認(rèn)為，掌握這些概念并正確理解這些概念的關(guān)系之后摊腋，就可以勝任使用 Kubernetes 部署微服務(wù)的工作沸版，為了使事情變得更簡(jiǎn)單，避免編寫冗長(zhǎng)的 YAML 文件兴蒸，Kuboard 以此概念為基礎(chǔ)视粮，設(shè)計(jì)了 Kuboard 工作負(fù)載編輯器，如下圖所示：

image-20190722162249531

#微服務(wù) + 監(jiān)控/評(píng)估

如何監(jiān)控和評(píng)估微服務(wù)的運(yùn)行狀況橙凳，并根據(jù)監(jiān)控結(jié)果進(jìn)行問(wèn)題的定位和診斷馒铃？基于 Kubernetes / Spring Cloud / Java 等，開(kāi)源社區(qū)已經(jīng)提供了非常豐富的監(jiān)控組件痕惋，例如：

• 資源層監(jiān)控：Prometheus + Grafana + Node Exporter 等組件区宇，監(jiān)控Kubernetes 節(jié)點(diǎn)的 CPU、內(nèi)存值戳、網(wǎng)絡(luò)议谷、磁盤等使用情況
• 中間件層監(jiān)控：Prometheus + Grafana + MySQL Exporter + Nginx Exporter + JVM Exporter 等，監(jiān)控 MySQL堕虹、Nginx卧晓、JVM 等中間件的使用情況
• 鏈路/APM監(jiān)控：Pinpoint / SkyWorking 等監(jiān)控工具，監(jiān)控應(yīng)用程序的性能表現(xiàn)

各種監(jiān)控系統(tǒng)各有側(cè)重赴捞，如果想要取得比較好的監(jiān)控效果逼裆，必須克服如下幾個(gè)困難：

• 搭建和配置監(jiān)控系統(tǒng)
• 定位和診斷問(wèn)題時(shí)，在不同監(jiān)控系統(tǒng)中來(lái)回切換赦政，進(jìn)入監(jiān)控系統(tǒng)并尋找對(duì)應(yīng)微服務(wù)的監(jiān)控結(jié)果

Kuboard 認(rèn)為胜宇，應(yīng)該以微服務(wù)視角的視角快速查看到該無(wú)服務(wù)在不同層面的監(jiān)控結(jié)果耀怜。因此，在 Kuboard 的工作負(fù)載（微服務(wù)）查看界面中桐愉，可以直接點(diǎn)擊進(jìn)入不同監(jiān)控系統(tǒng)對(duì)應(yīng)的監(jiān)控結(jié)果财破，無(wú)需再監(jiān)控系統(tǒng)內(nèi)反復(fù)查找。如一下截圖所示：

image-20190809220543742

點(diǎn)擊圖中 Nginx 監(jiān)控从诲、 容器組監(jiān)控左痢、 所在節(jié)點(diǎn)監(jiān)控 等按鈕，可以直接打開(kāi)該容器組對(duì)應(yīng)的監(jiān)控界面系洛。因?yàn)槠南拗瓶⌒裕颂幉辉僬归_(kāi)描述，請(qǐng)到 www.kuboard.cn Kuboard 官網(wǎng) 提供的在線Demo體驗(yàn)具體的監(jiān)控效果描扯。

#總結(jié)

Kuboard 產(chǎn)生于 Spring Cloud 微服務(wù)落地的實(shí)踐中定页，并在許多的實(shí)際項(xiàng)目中投入了使用，以微服務(wù)的視角理解和審視了 Kubernetes荆烈，并基于Kubernetes為用戶提供了4個(gè)微服務(wù)視圖：

• 集群概覽視圖
• 名稱空間視圖
• 工作負(fù)載視圖
• 監(jiān)控視圖

目前 Kuboard 已經(jīng)可以免費(fèi)供大家使用拯勉，感性的朋友可訪問(wèn) www.kuboard.cn 獲得詳細(xì)的信息。